Add specialized pair construction API #3990
Conversation
| ZEND_API HashTable* ZEND_FASTCALL zend_new_pair(zval *val1, zval *val2) | ||
| { | ||
| Bucket *p; | ||
| HashTable *ht = emalloc(sizeof(HashTable)); |
There was a problem hiding this comment.
How aggressive do you want to be here ?
Might it be possible to make alloc for ht+buckets one allocation, might it also be possible to omit hash_init_int, and write a hash_init_pair (in place of real_init_packed) ?
There was a problem hiding this comment.
Would love to combine those allocations, but I don't think it's possible. The rest of the hash API assumes that these are separate allocations, and in the end the pair is still a normal array and can be used as such.
There was a problem hiding this comment.
That's a shame ... what about a specialized init ? among other things, init_int sets flags and then immediately real_init_packed sets them otherwise ? it looks like you could avoid the persistent branch in real_init too ?
There was a problem hiding this comment.
I would hope that all of this will get optimized because these functions are always_inline, but I'll have to check assembly to be sure.
|
On latest version of remex-html benchmark (with fixes to ensure the character reference regexp doesn't go through the slow path in zend_hash_find): Callgrind cycles spent in php_pcre_match_impl: So a nice 4.4% speed improvement with what seems like not too much extra code complexity. The populate_subpat_array function accounts for: So still a substantial fraction of the overall pcre match time. @nikic had the idea of returning a lazy object as |
|
@dstogov Is adding this kind of API okay? It's a small optimization for pcre. |
|
looks fine |
Add a
zend_new_pair()function for creating a pair array. This cuts down instructions for subpat population from 67k to 52k on a remex-html benchmark.